home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Supervisor's Toolkit
/
Network Supervisor's Toolkit.iso
/
communic
/
pcbridge
/
src.doc
< prev
next >
Wrap
Text File
|
1996-07-10
|
10KB
|
205 lines
PCbridge source code description
Vance Morrison
PCbridge is distributed with source for essentially one reason, I would
like to involve many people in the design and debugging of PCbridge, and for
them to do this, they need the source. Since I will not be the only one
fixing bugs and adding enhancements, PCbridge will continue to develop as long
as there are people who think it is a worthwhile program to support. As
creator of PCbridge, however I request/demand the following
1) Please let me know about any bug fixes so that I can incorporate
them into the 'official' release.
2) You may make local enhancements to PCbridge and use them LOCALLY
(that is within the same organization) but you may NOT distribute
this code.
The reason for the second demand (it is in the copywrite) is very simple,
I don't want PCbridge to fragment into many versions. That is my ONLY
concern. Thus just tell me what you want to do, and I will give you
an copy of the working source code, and you can be sure that the part that
you are working on is not being worked on by anyone else, and when you are
done it will be ready to integrate into the official release. I do
reserve the right NOT to integrate features that I regard as counterproductive
and code that simply is too poorly written or buggy to risk, but I do not
see myself excercising that option.
All of these conditions are simply to insure that PCbridge has a long
and productive life. I have no monetary interest in PCbridge.
============================================================================
DESIGN CRITERIA
PCbridge had to be designed to squeeze all the power it could out
of an 8088 CPU. As such I had to make some rather drastic measures.
These include
1) Programming the main packet routing loop in assembler
2) NO procedure call in the main packet routing loop
Since assembler have very good macro expansion capabilities, the
second decision is relatively painless. Simply use macros instead
of procedure calls. This can make the code large, but memory has
not been a problem yet.
Once we are out of the main packet loop, these optimizations are
not really necessary anymore. Thus if/when SNMP support is added
to PCbridge, it will be done in C, since all of this code is only
executed when SNMP operations are being done.
===========================================================================
CONVENTIONS
Despite the use use of assembler, I have tried to make the code
as modular as possible, and to adopt conventions that I have found quite
useful in preventing common assembly code errors. Some of these
conventions are
1) function prefixing - Macros are groups into modules that provide
a set of related services. All function in this group are
prefixed by the same short string. This improves readability
and prevents name conflicts
2) Naming input, output and constant registers - The most common
error in assembly code is calling a macro that changes registers
that you believed where held constant. To prevent this type
of error Macro names have the following form
<NAME>_in_<REG LIST>_out_<REG_LIST>_const_<REG_LIST>
For example
WD_IF_COPY_in_CX_SI_DI_ES_out_SI_DI_const_BX_BP_ES name
It is quite clear from the name that this macro has its parameters
passed in CX,SI,DI,ES, it returns values in SI,DI and it holds
the registers BX,BP,ES constant. While this may seem long-winded
(it is) it is VERY useful and has prevented many bugs and I
will DEMAND that any new assembly code follow these conventions.
Note that since the CS,DS,SS registers are NEVER changed, you
may assume that EVERY macro preserves these registers.
3) file naming - There are two type of files in the source code at
present, INC files and ASM files. INC files contain ONLY macro
definitions and admit NO code and are meant to be included in
ASM files. INC file are thus the 'meat' of the code. The ASM
files contain NO macro definitions, but do instantiate the macros
to generate the actual code. At present there is only one
ASM file (BRIDGE.ASM).
===========================================================================
The IF interface:
The IF interface is a device-independant view of a network card. Thus
new hardware can be supported simply by writing code to implement an
IF interface for the new hardware.
IF.INC Supplies a standard interface for all card specific
code and dispatches the proper code when generic
routines are called.
===========================================================================
IF interfaces for 3COM 3c507 Ethernet:
The following file implement a IF interface for 3COM 3c507 card
3C507.INC IF interface specific to the 3c507.INC file
===========================================================================
IF interfaces for WD Ethernet and Starlan code:
The following files implement a IF interface for Western digital cards
WD8003E.INC IF interface specific to the WD8003E, WD8003EBT
and WD8013EBT cards. It also works with WD8003S
and WD8003SH starlan cards, but the buffering
is not optimized for these slower cards.
WD.INC Constant declarations needed by the above two
modules to manipulate the WD8003 card.
==========================================================================
IF interface for the packet driver
PACKET.INC Implements an IF intererface for FTP software's
packet driver specification. Since many packet
drivers have been written for may cards, this
module immediately provides support for all these
cards. Unforunately, the packet driver specification
is not highly optimized for throughput, thus this
interface is usually 1/3 the speed of a 'native'
IF interface.
==========================================================================
IF interface for a serial COM port
I8250.INC Implements code for getting and putting single
characters on and off a 8250 serial chip. It
also has support for the 166550AF chip with FIFOs.
This module is the only one that has to deal with
the vugarities of setting interupts and dealing
directly with the serial chip.
SLIP.INC The stream of input characters from the I8250
interface and packatizes them according to the
SLIP protocol. Also adds packet markers to
outgoing packets producing a outgoing character
stream that the I8250 module transmits.
QIF.INC Impelents the 'other half' of the packet queuing.
It is this code that queues up incomming and
outgoing packets. It looks like a IF interface
to higher levels.
==========================================================================
The Bridge Code:
BRIDGE.INC This file implements the actually packet bridging
algorithm. In addition, it also acts like a IF
interface. The idea is that any packets that are
not addressed to the bridge are inspected and
bridged if necessary, however if a packet is sent
directly to the address of the bridge this packet
is sent to the higher level (via an IF interface)
for processing. This allows the possibility for
Bridge-routing or network control (SNMP).
BRIDGE.ASM The 'main program' for the bridge. This file
is only one you should need to change to reconfigure
the bridge (see compile.doc).
===========================================================================
Support routines
In addition to the major functional blocks, there are some modules that
provide rather generic services that are used by the other functional blocks.
These modules include
DEBUG.INC Provides simple routines that print to screen routines.
They should not be in production code (use log routines)
These routines violate convention in that they
preserve ALL registers but do not have a CONST
part in their name.
BUFFER.INC Provides simple buffer allocation routines used in
output (and possibly input) queuing. Used in
QIF.INC ATALK.INC and WD8003.INC
QUEUE.INC Provides simple queuing routines used for packet
queues. Used in ATALK.INC and WD8003.INC
==========================================================================